:released: February 4, 2020

 .. change::
     :tags: change

     The internal inspection routines no longer use SQLAlchemy's
     ``Inspector.from_engine()`` method, which is expected to be deprecated in
     1.4.  The ``inspect()`` function is now used.


 .. change::
     :tags: bug, autogenerate
     :tickets: 647

     Adjusted the unique constraint comparison logic in a similar manner as that
     of :ticket:`421` did for indexes in order to take into account SQLAlchemy's
     own truncation of long constraint names when a naming convention is in use.
     Without this step, a name that is truncated by SQLAlchemy based on a unique
     constraint naming convention or hardcoded name will not compare properly.


 .. change::
     :tags: feature, batch
     :tickets: 640

     Added new parameters :paramref:`.BatchOperations.add_column.insert_before`,
     :paramref:`.BatchOperations.add_column.insert_after` which provide for
     establishing the specific position in which a new column should be placed.
     Also added :paramref:`.Operations.batch_alter_table.partial_reordering`
     which allows the complete set of columns to be reordered when the new table
     is created.   Both operations apply only to when batch mode is recreating
     the whole table using ``recreate="always"``.  Thanks to Marcin Szymanski
     for assistance with the implementation.

 .. change::
     :tags: usecase, environment
     :tickets: 648

     Moved the use of the ``__file__`` attribute at the base of the Alembic
     package into the one place that it is specifically needed, which is when
     the config attempts to locate the template directory. This helps to allow
     Alembic to be fully importable in environments that are using Python
     memory-only import schemes.  Pull request courtesy layday.

 .. change::
     :tags: bug, autogenerate
     :tickets: 605

     A major rework of the "type comparison" logic is in place which changes the
     entire approach by which column datatypes are compared.  Types are now
     compared based on the DDL string generated by the metadata type vs. the
     datatype reflected from the database.  This means we compare types based on
     what would actually render and additionally if elements of the types change
     like string length, those changes are detected as well.  False positives
     like those generated between SQLAlchemy Boolean and MySQL TINYINT should
     also be resolved.   Thanks very much to Paul Becotte  for lots of hard work
     and patience on this one.

     .. seealso::

         :ref:`autogenerate_detects` - updated comments on type comparison

.. changelog::

:released: January 22, 2020

 .. change::
     :tags: bug, postgresql
     :tickets: 637

     Fixed issue where COMMENT directives for PostgreSQL failed to correctly
     include an explicit schema name, as well as correct quoting rules for
     schema, table, and column names.  Pull request courtesy Matthew Sills.

 .. change::
     :tags: usecase, operations
     :tickets: 624

     Added support for rendering of "computed" elements on :class:`.Column`
     objects, supported in SQLAlchemy via the new :class:`.Computed` element
     introduced in version 1.3.11. Pull request courtesy Federico Caselli.

     Note that there is currently no support for ALTER COLUMN to add, remove, or
     modify the "GENERATED ALWAYS AS" element from a column;  at least for
     PostgreSQL, it does not seem to be supported by the database. Additionally,
     SQLAlchemy does not currently reliably reflect the "GENERATED ALWAYS AS"
     phrase from an existing column, so there is also no autogenerate support
     for addition or removal of the :class:`.Computed` element to or from an
     existing column, there is only support for adding new columns that include
     the :class:`.Computed` element.  In the case that the :class:`.Computed`
     element is removed from the :class:`.Column` object in the table metadata,
     PostgreSQL and Oracle currently reflect the "GENERATED ALWAYS AS"
     expression as the "server default" which will produce an op that tries to
     drop the element as a default.

.. changelog::

:released: December 16, 2019

 .. change::
     :tags: bug, api, autogenerate
     :tickets: 635

     Fixed regression introduced by :ticket:`579` where server default rendering
     functions began to require a dialect implementation, however the
     :func:`.render_python_code` convenience function did not include one, thus
     causing the function to fail when used in a server default context.  The
     function now accepts a migration context argument and also creates one
     against the default dialect if one is not provided.


.. changelog::

:released: November 13, 2019

 .. change::
     :tags: bug, mssql
     :tickets: 621

     Fixed bug in MSSQL dialect where the drop constraint execution steps used
     to remove server default or implicit foreign key constraint failed to take
     into account the schema name of the target table.


.. changelog::

:released: October 31, 2019

 .. change::
     :tags: feature, command
     :tickets: 608

     Added support for ALEMBIC_CONFIG environment variable,
     refers to the location of the alembic configuration script
     in lieu of using the -c command line option.


 .. change::
     :tags: bug, autogenerate
     :tickets: 131

     Fixed bug in new Variant autogenerate where the order of the arguments to
     Variant were mistakenly reversed.

 .. change::
     :tags: change, compatibility

     Some internal modifications have been made to how the names of indexes and
     unique constraints work to make use of new functions added in SQLAlchemy
     1.4, so that SQLAlchemy has more flexibility over how naming conventions
     may be applied to these objects.

.. changelog::